%\section{The Banking Scenario, Revisited}\label{s:examp}
Consider the client-server scenario discussed in the Introduction, described by process $Sys$.
In our process model, we give the following specification for $M_\locf{ser}$, explicitly distinguishing between internal and external requests:
\begin{eqnarray*}
M_\locf{ser} & =  & \que{\locf{ser}}{\epsilon} \para \mu \rv{X}.\ifte{\arrive{\locf{ser}, \mathtt{upd}_I}}{A_\locf{ser}}{\rv{X}}
 \\
& & \qquad  ~~\para \mu \rv{X}.\ifte{\arrive{\locf{ser}, \mathtt{upd}_E}}{B_\locf{ser}}{\rv{X}}
\end{eqnarray*}
Observe that   $M_\locf{ser}$ includes three components: (a)~the queue for adaptation requests (internal or external) for the service
at \locf{ser}; (b)~a process ready to react if an internal adaptation request arrives;
and (c)~a process which reacts to external adaptation requests. 

Suppose now that client and 
service in $Sys$ interact on $u$ to establish the session. 
Assume further that the client's body $R_y$ includes, in addition 
to their communication behavior, 
 the issue of an adaptation request 
for the service. 
This is a natural possibility for clients, for they would like to interact with the latest available version of the service:
\begin{equation}
R_y = \outC{\locf{ser}}{\mathtt{upd}_I} \para \select{y}{w};\select{y}{n_2};R'_y \nonumber
\end{equation}
Hence, after the synchronization on $u$ we obtain:
\begin{eqnarray*}
Sys & \pired  & \scomponentbig{\locf{bank}}{\scomponent{\locf{ser}}{\branchbig{\cha^+}{ b{:}Q_{\cha^+} \alte w{:}\branch{\cha^+}{n_1{:}P_{\cha^+}^1 \alte n_2{:}P_{\cha^+}^2}} \para \que{\cha^+}{\ST} \para M_\locf{ser}}} \para \\
&   & ~\scomponentbig{\locf{cli}}{\outC{\locf{ser}}{\mathtt{upd}_I} \para \select{\cha^-}{w};\select{\cha^{-}}{n_2};R'_{\cha^{-}}  \para  \que{\cha^-}{\STT}} = Sys_1
\end{eqnarray*}
In a setting with distributed resources and services, it is hard to predict  when the adaptation request issued by the client will  actually be served. This leads to the question: when the request is finally handled, what should be the appropriate adaptation routine for endpoint $\cha^+$? That is, what should be the actual structure of process $A_\locf{ser}$? Let us assume the following alternatives:
\begin{enumerate}[(a)]
\item If the first branching has not been  decided yet (the actual session has not yet started), then add an extra service $l_3{:}Q'$.
\item If both labels $l_2$ and $n_1$ have been selected by the client, then offer an new behavior that replaces $P_{\cha^+}^1$.
Proceed similarly if both $l_2$ and $n_2$ have been selected.
\item Otherwise, if  none of the above options apply then  keep the service as it is.
\end{enumerate}
These alternatives critically rely on the possibility of referring to concrete states within the structure of the session. As such, it goes beyond the adaptation routines expressible in our previous work~\cite{GiustoP14}. We now illustrate how an adaptation routine capturing (a)--(c) can be expressed in our framework. Let us define the following process for $A_\locf{ser}$:
\begin{eqnarray*}
A_\locf{ser}  =  \nadaptbig{\locf{ser}}{\mathsf{case}\,x\,\mathsf{of}\{(x{:}\ST):P^* ~\alte~ (x{:}\ST_{21}):P^3_{x}  ~\alte~ (x{:}\ST_{22}):P^4_{x} \, \}} 
\end{eqnarray*}
where 
$P_x^3$ (resp. $P_x^4$) is an alternative implementation for $P_x^1$ (resp. $P_x^2$), and $P^*$ stands for 
the following extended service definition:
\begin{eqnarray*}
\branchbig{x}{ l_1{:}Q_x \alte l_2{:}\branch{x}{n_1{:}P_x^1 ~\alte n_2{:}P_x^2} \alte l_3{:}Q'_x}
\end{eqnarray*}
With this definition for $A_\locf{ser}$, adaptation can be enforced independently of the actual moment in which 
the internal adaptation request is issued and detected by $M_\locf{ser}$.


%Given the coupling between the arrive predicate and update processes, 
%the latter should not occur freely in the process structure, but guarded within conditional constructs that enable adaptation depending on the arrival of some adaptation request. 
%Hence, upon arrival of an adaptation request, such conditional constructs will release the previously guarded update processes, and adaptation may   take place, depending on both the state of the protocols in the given location and the matching options specified by the update process. 


There are several remarkable points in this example.
First, notice the coupling between the arrive predicate and eventful update processes enforced by $M_\locf{ser}$:
the latter occur guarded within a conditional which depends on the arrive predicate at some given location.
%In the model of \S\,\ref{s:arch} we formalize this coupling of update processes and arrive predicates via conditionals.
Also, note that the adaptation routine given by $A_\locf{ser}$
specifies the cases in which a concrete behavior modification is meant to occur at runtime. 
This is enough, for our semantics includes a ``default'' adaptation: 
if none of the specified cases holds, then the current state of the session will be kept in location $\locf{ser}$.
Moreover, observe that the update process in $A_\locf{ser}$ corresponds to the simple case in which only one session needs to be taken into account. Eventful update processes can handle an arbitrary (but finite) number of sessions. 
%This could come in handy when considering, for instance, a location with several different clients for the same service. 
Finally, it is interesting to notice that external adaptation requests are treated analogously. 
Location identities (such as \locf{ser} or \locf{cli}) are public; as such, they could be visible to the   environment
for adaptation purposes. We believe that this brings uniformity to specifications, and allows us to consider open systems for adaptation purposes.
